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Abstract 


Malware plays a critical role in breaching computer 
systems. The computing behavior of a register machine 
program can be sabotaged, by making a very small 
change to the original, uninfected program. Stability 
has been studied extensively in dynamical systems and 
in engineering. Our primary contribution introduces 
a computing machine that is structurally stable to 
small changes made to its program instructions. 
Our procedures use quantum randomness to build 
unpredictable stable instructions. Our procedures can 
execute just before running a program so that the 
computing task can be performed with a different 
representation of its instructions during each run. 

Our procedures are inspired by the Red Queen 
hypothesis in biology: organisms evolve using 
robustness, unpredictablity and_ variability to 
hinder infection. Another contribution expands the 
mathematical notion of stability to a cryptographic 
model with an adversary, and explains why structurally 
stable machines can be resistant to malware sabotage. 


1. Introduction 


Malware plays a critical role in breaching computer 
systems. Cybersecurity research has primarily focused 
on malware detection [1]. It seems unlikely that 
malware detection methods can solely provide an 
adequate solution to the malware problem: There does 
not exist a register machine algorithm that can detect 
all malware [2]. Furthermore, some recent malware 
implementations use NP problems [3] to encrypt and 
hide the malware [4]. Overall, detection methods are 
currently up against fundamental limits in theoretical 
computer science. 

The instability of register machine computation 
[5] enables malware to sabotage the purpose of a 
computer program, by making small changes to one or 
more instructions in an original, uninfected program. 
Programming languages such as C, Java, Lisp and 
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Python rely upon register machine [6] branching 
instructions. One sabotaged branching instruction 
enables malware to start executing. Even if there is a 
routine to verify that the program is executing properly, 
this verification routine may never execute. Sequential 
execution of unstable register machine instructions 
cripples the program from protecting itself [7]'. 

Prior mathematical research has not attempted 
to design malware resistant computation based on 
structural stability. For over 80 years, dynamical 
systems has extensively studied structural stability [8, 9] 
on phase spaces [10], containing an uncountable number 
of states [11]*. During execution of a register machine, 
the machine’s state at any moment lies in a discrete 
space, containing a countable number of states. 

Based on dynamical systems and information theory, 
our primary contribution develops mathematical and 
computational tools to build a structurally stable 
sequential machine that is resistant to small changes to 
the program instructions. Our approach is inspired by 
the Red Queen hypothesis [12] in evolutionary biology: 
organisms evolve using robustness, unpredictability 
and variability to hinder infection from parasites. 
Another contribution expands the notion of stability to 
a cryptographic model with an adversary, and explains 
why this structurally stable machine is resistant to 
malware sabotage. 


2. Motivating Stable Computation 


Register machines execute one instruction at a time. 
Even if there is a procedure to assure that the register 
machine program is executing correctly, this friendly 
procedure may never execute due to just one rogue 
branch instruction. | Typical programming languages 
(e.g., C, Fortran, Java, Lisp and Python) 
are Turing complete and depend upon branching 

'Non-register machines, such as the Active Element Machine [7], 
can execute multiple machine instructions simultaneously. 

2A space X is uncountable if X contains an infinite number of 
states and there does not exist a 1-to-1 correspondence between X 


and the natural numbers N. A space X is countable if there exists a 
1-to-1 correspondence between X and N. 
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instructions. While conditional branching instructions 
are not required for universal computation, Rojas’s 
methods [13] still use unconditional branching and 
program self-modification. Moreover, about 75% to 
80% of the control flow instructions, executed on 
register machines, are conditional branch instructions.? 

These observations suggest that a computer 
program’s purpose can be subverted because the register 
machine behavior is not always invariant when small 
changes are made to one or more instructions. 

Overall, we seek stable computation based on the 
following design principle: if a small or moderate 
change is made to a register machine program, then the 
program’s purpose is stable; if a large change is made, 
the program can no longer execute. Our principle is 
partly based on the observation that it is generally far 
more difficult to detect if a small change has altered 
the purpose of a program. With a small change, the 
tampered register machine program still can execute, but 
does not perform the task that the original program was 
designed to accomplish. For this reason, our goal is to 
create stable computation that is also incomprehensible 
to malware authors so that it is far more challenging 
for malware to subvert the program without completely 
destroying its functionality. 


3. An Unstable C Program 


We demonstrate unstable computation with C source 
code [14] that adds 3 integers. This C code shows how 
a 1-bit change to the address of only one instruction can 
substantially alter the program’s behavior. 


#include <stdio.h> 


#define NUM_BITS 16 

int pow2[NUM_BITS] = {0x8000, 0x4000, 0x2000, 0x1000, 
0x800, Ox400, 0x200, 0x100, 
0x80, 0x40, 0x20, 0x10, 
Ox8, 0x4, Ox2, Oxl1}; 


int addition(int a, int b) 
{ 
return (a + b); 


} 


int multiply(int a, int b) 
{ 
return (a * b); 


} 


int exec_op(int* num, int n, int (*op) (int, int) 
{ 
int i, v = num[0]; 
for(i = 1; 4 < ny i++) 
i 
v = op(v, num[i]); 


return v; 


3See figure A.14 in [5]. 


void print_numbers(int* v, int n) 
{ 
int k; 


printf ("\n"); 
for(k = 0; k < n; k++) 
{ 
printf("Sd ", v[k] ); 
} 
} 


void print_binary (unsigned int v) 
{ 
int k; 


for(k = 0; k < NUM_BITS; k++) 

{ 
if (v / pow2[k]) printf("1 "); 
else printi(™d "5 


v %= pow2[k]; 
} 
printf("\n"); 
} 


int bop(int* m, int n, char« f, int (*op) (int, int) 
{ 


int v = exec_op(m, n, op); 


printf("\nresult = %d. address of ", v); 
printf("Ss = \n", £); 
print_binary((unsigned int) op); 


return 0; 


} 


int main(int argc, char* argv[]) 
{ 
int num[3] = {2, 3, 5}; 


print_numbers(num, 3); 

printf ("\n"); 

bop(num, 3, "addition", addition); 
bop(num, 3, "multiply", multiply); 


return 0; 


aemea@Michaels-MacBook-Air C_program % ./ADD 
235 


result = 10. address of addition = 
101012100010%310000 


result = 30. address of multiply = 
1010110001%1310000 


Figure 1. Sum Changed to a Product 


Figure 1 shows an execution of the compiled C 
program: ADD. A sum 2 + 3 + 5 is converted to a 
product 2 « 3 * 5, by flipping only one bit of the address 
of instruction addition. This C program exhibits 
unstable computation because a small change (flipping 
one bit) in the C program causes a substantial change to 
the outcome: namely, a sum equal to 10 is changed to a 
product equal to 30. 
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4. Cryptographic Model Assumptions 


In our model, Alice’s goal is to hinder Eve 
(malware author) from sabotaging Alice’s computation. 
Additional assumptions about what information Eve 
has access to are more appropriate to discuss after 
a comprehensive description of our structurally stable 
machine is provided. Some of these assumptions defer 
prospective hardware implementations to a subsequent 
paper. Bob is not part of our model. We do not address 
commmunication between Alice and Bob, as is typical 
with a public key exchange. 


5. Structural Stability 


Structural stability is a mathematical tool that can 
be applied to computer programs because a register 
machine program can be modeled as a discrete, 
autonomous dynamical system [15]. When a perturbed 
instruction is close enough to an original instruction 
that is stable, then the computational behavior of the 
program will not change. For this reason, structural 
stability can be used to design a solution that hinders 
malware sabotage. We briefly review topological 
spaces, metric spaces and structural stability. 


5.1. Topological Spaces & Metric Spaces 


A topology [11] on a set X is a collection 7 of 
subsets of X having the following properties: (a) @ and 
X are both in 7; (b) The union of the elements of any 
subcollection of J is in 7; (c) The intersection of the 
elements of any finite subcollection of 7 isin J. A set 
X for which a topology 7 has been specified is called 
a topological space. A subset U of X is called open 
in this topology if U belongs to the collection 7. The 
standard topology on R (real numbers) is generated from 
arbitrary unions of open intervals and finite intersections 
of open intervals, where an open interval is (a,b) = 
{cE R:a<a< bd}. 


For topological spaces X (domain) and Y (range), a 
function f : X — Y is continuous if for any open subset 
U of Y, the inverse image f-1(U) = {x € X : f(x) 
lies in U} is open in X’s topology. A function h : X > 
Y is a homeomorphism if h is continuous, h is bijective 
and h’s inverse h~! : Y — X is continuous. 


A metric space is a set X and a function (metric) 
d:X x X — R such that all three conditions hold: (1) 
d(a,b) > 0 for all a,b € X where d(a,b) = 0 if and 
only if a = b. (2) d(a,b) = d(b,a) for all a,b € X. 
(3) d(a,b) < d(a,c) + d(c, b) for all a,b,c € X. 


5.2. Topological Conjugacy & C° Stability 


A discrete, dynamical system is a function f : X 
X, where X is a topological space. Two dynamical 
systems f : X > X andg: Y — Y are topologically 
conjugate if f and g are continuous and there exists a 
homeomorphism h : X — Y such thatho f=goh. 

Let (X,d) be a metric space. The C® distance 
between functions f : X > X andg: X > X is given 
by po(f,9) = sup{d( f(x), g(x) : x € X}, where sup 
is the least upper bound. A function f : X — X is said 
to be C® structurally stable on X if there exists « > 0 
such that whenever po(f,g) < ¢ for g : X > X, then 
f is topologically conjugate to g. In other words, f is 
structurally stable if for all dynamical systems g that are 
close to f, then f is topologically conjugate to g. 

After a register machine has halted, its halted 
machine configuration represents what the machine has 
computed. Topological conjugacy is useful because 
each halted machine configuration corresponds to a 
fixed point (halting point) of a dynamical system that 
faithfully models the register machine. If h is a 
topological conjugacy with ho f = go h, then p is 
a fixed point of f if and only if h(p) is a fixed point. 
Hence, a topological conjugacy between machines J, 
and Mo induces a 1|-to-1 correspondence between the 
halting configurations of M, and Mo. 


6. A Structurally Stable Machine 
We have two design goals, motivated by section 2: 


A. Build instructions that are invariant to small 
changes in their representation. 


B. Hinder the adversary from figuring out how to 
manipulate these machine instructions. 


We start with a Turing complete, virtual machine, as 
a starting point for building computation that satisfies 
our two design goals. We describe procedures* that 
transform these virtual machine instructions: these 
transformation procedures represent and execute the 
functionality of the virtual machine instructions so 
that the computation is stable under small changes 
to the transformed instructions. Furthermore, these 
transformed instructions also satisfy design goal B. 


6.1. A Virtual Register Machine 


Below is a brief description of the instructions for 
our virtual machine. Our transformation procedures, 


4Comprehensive hardware implementation(s) of these procedures 
are beyond the scope of this paper. 
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applied to these virtual machine instructions, are 
described in subsections 6.2, 6.4, 6.5 and 6.6. 


SET A 14 stores 14 in register A. 


ADD B C_ adds the contents of registers B and C and 
stores the sum in register B. 


SUB C 13 subtracts 13 from the contents of register 
C and stores the difference in register C. 





MUL D C_ multiplies the contents of register D and 
register C and stores the product in register D. 


DIV A 7. divides the contents of register A by 7 and 
stores the quotient in register A. If A contains 26, then 
after DIV A 7 is executed register A contains 3. 


MOD A 7 divides the contents of register A by 7 and 
stores the remainder in A. If register A contains 26, then 
after MOD A 7 is executed register A contains 5. 


JMP L_AB updates the program counter to execute 
the instruction tagged by label L_AB. If L_AB contains 
37, then instruction 37 will be executed next. JMP acts 
as an unconditional branch instruction. 


IF A B_ executes the next instruction if the contents 
of register A equals the contents of register B. Otherwise, 
the next instruction is skipped. 


IFN C 5 executes the next instruction if the contents 
of register C are not equal to 5. If register C contains 5, 
the next instruction is skipped. 


IFGT C 12. executes the next instruction if the 
contents of register C are greater than 12. If register C 
contains a number less than 13, the next instruction is 
skipped. 


The opcode for instruction name SET represents 
SET in terms of bits. The other instruction names 
{ADD, SUB, MUL, DIV,MOD, JMP, IF, IFN, IFGT, 
STORE, GET} each have their own unique opcode 
in terms of bits. An opcode is mathematically defined 
as a function 0 : {SET, ADD, SUB, MUL, DIV, MOD, 
JMP, IF, IFN, IFGT, STORE, GET} — {0,1}” such 
that O is 1-to-1. 1-to-1 means 9 maps two different 
instruction names to two distinct n-bit strings. 

A valid instruction starts with an instruction name, 
followed by one or two operands. In instruction 
IFGT C 12, register C is the first operand and the 
number 12 is the second operand. The JMP instruction 
is the only instruction with one operand. 

In subsection 6.6, example | implements a greatest 
common divisor algorithm with this virtual machine. 
In subsection 6.2, we develop computational tools 
that transform these instructions so that the program 
instructions are hidden, stable and unpredictable. 
































6.2. Randomizing Instruction Opcodes 


We describe a procedure that randomizes opcodes 
such that each opcode is a minimal Hamming distance 
apart. Our random opcode procedure is a computational 
tool for helping us achieve our two design goals. 

First, we review some definitions from information 
theory. {0,1}” is the collection of all n-bit strings, 
where each binary string a in {0,1}” can represent an 
opcode of a virtual machine instruction. Sometimes b 
in {0, 1}? can represent an operand of a virtual machine 
instruction, and in some cases n # p. 

Let a = aj,...G@y and b = 0bj,...by be binary 
strings of length n. For each n, the Hamming metric 
[16] is defined as d(a,b) = >> la; — b;|. It is easy to 

i=1 
verify that ({0, 1}”, d) is a metric space per section 5.1. 

Note d(0010,0111) = 2. Consider string c = 
Cy... Cp in {0,1}". A Hamming ball H(c,m) = {a € 
{0,1}” : d(c,a) < m} has center c and radius m. 

Let q be a quantum random bit generator> [17]. 
Based on a quantum measurement, qg returns a random 
0 or 1. In procedures 1, 2, and 3, q helps construct 
m distinct random opcodes each of length n that are 
pairwise a minimum Hamming distance of 2/ + 1 bits 
apart. These procedures build random opcodes that are 
stable, when there are at most / bits of sabotage on a 
single opcode. A random opcode J; is the center of a 
Hamming ball with radius /. Geometrically, all opcodes 
in H(I,,1) can be repaired to the correct opcode I. 

Procedure 1 builds an n-bit random opcode 
Lj ilj2...Ljn used by instruction [;, after quantum 
random bit generator g measures n random bits. 


Procedure 1. = Random Opcode 
Input: n 
set k:=1 


while k<n 
{ 


set Ij;~ to a random bit measured by qg 


increment k by 1 


} 
Output: Ij Ij.2 fads Len 


The jth random opcode, called J;, is n bits long. 
Procedure 2 begins with m random opcodes Jy, I2,..., 
Im as input. Procedure 2 finds two distinct opcodes in 


5We prefer a QRNG over a CSRNG based on the following 
principle: no sentient being can capture or steal information that does 
not yet exist. According to quantum theory, a quantum random bit 
does not exist until a measurement occurs. A CSRNG’s effectiveness 
depends upon on an algorithm: any Turing machine, implementing 
the algorithm, violates our principle, and relies on a seed. A CSRNG 
provides no unpredictability if the seed is known. A CSRNG also begs 
the question: how is an unpredictable seed generated? 
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{h, In, ... 
hy, apart. 


, Im} that are a smallest Hamming distance 


Procedure 2. 
Input: m,n, and opcodes {h, I2,..., Im} 


Minimal Hamming Pair 


set hy :=n+1 
set i:=1 


while 7<m 


{ 
set g:=i+l1 
while j<m 
{ 
set hi= d(Ji, I;) in {0, 1}" 


if (h<h,) 

{ 
set h,:=h 
set tyi=1 
set Jui=J 


} 
increment 7 by 1 
} 


increment 7 by 1 


} 


Output: Ti, Tj, Ay 


Procedure 3 uses procedures 1 and 2 to build m 
random opcodes (n-bit codes) that are pairwise at least 
a Hamming distance of 2/ + 1 apart. 


Procedure 3. 
Input: l,m,n 


Minimal Hamming Distance 


call procedure 1m times with input n: 
output fh,...,Im 


call procedure 2 with input h,...,Im: 


output Ji, Ij, hy 


pe? 


set r:=0 


while h, < (2l+1) 
{ 
set b:=214+1-hy 


do b times 
{ 


use q to randomly choose positive 
integer k in the set {1,2,...,n} 


flip bit k in kh, 
} 


xecut 2 with input h,...,Im 





procedur 


increment r by 1 


} 
Output: 1... Im with d(1j,Ip) > 2I+1 when j #k 


Flip bit k means: if the kth bit is 0, then set the 
kth bit to 1; and if the kth bit is 1, then set the kth 
bit to 0. Variable r counts the number of repairs on 
a random opcode until any two distinct opcodes are at 
least a distance of 2] + 1-bits apart. 2/ + 1 should be 
about 1 to 2.5 standard deviations less than 5 so that 
outer loop while h, < (21+1) promptly exits.® 

If J is too large (e.g., (21 + 1) > n), then the outer 
loop never exits and r — oo. To avoid long computing 
times, a variation of procedure 3 inserts, before the outer 
loop, set 1 =|4(n— c/n) — $|, where 1 <c < 8. 

In our cryptographic model, Alice’s m random 
opcodes 11, [2,... I, “act as her private keys.” Hence, 
her random opcodes should be generated and stored in 
Protected Machine Hardware (blue region in Figure 2) 
so that procedure 3 can help assure anonymity and valid 
execution of her instructions. It is also good practice for 
Alice to keep / private. 











Unprotected Memory 
Random Access Memory 
Long Term Memory 


Figure 2. Eve cannot access the blue region. 





6.3. Instruction & Program Stability 


We formally define instruction and program stability. 


Definition 1. A set of opcodes (or operands) 
{h,...,Im} is s-bit stable if min{d(I,;, I.) : 7 Ak} = 
s. In other words, if I; and I;, are the closest opcodes 
(operands) in {I,,..., Im}, then d(I;, In) > s. 


Definition 2. An n-bit instruction I is s-bit stable if its 
opcode and operands are both s-bit stable. 


Remark 1. The random opcodes generated by a 
successful exit of procedure 3 are 2/ + 1-bit stable. 


Procedure 2 returns h,,. h,, is the minimum distance 
between any two distinct opcodes in {l),...,Im}. A 
successful exit of procedure 3 means the loop while 
hy < (21+ 1) exited; hence, h,, > 21+ 1. 

6n 


2 


codes, where each bit occurs with probability 5. The standard 


vn 
oan 


is the expected Hamming distance between two random n-bit 


deviation of uniformly random n-bit codes is 
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Using definitions 1, 2 and remark 1, we can explain 
the stability of programs, transformed by procedures 
1-3, in terms of the theory of section 5. First, we need 
to define a metric on a space of programs, where each 
program is a finite sequence of transformed (procedures 
1-3) instructions (before hiding). Consider a program 
of transformed instructions P, = (11, I2,...,Im) and 
another program of transformed instructions P, = 
(Ji, Jo,...,Jm). If two programs have the same length 
m, define the distance between them as D(P1,P2) = 
max{d(I,, Jn) : 1 < k < m}. If programs P and Q 
have different lengths, then define D(P, Q) = n, where 
all program instructions in P and Q lie in {0,1}”. 

Assume each instruction J,, for 1 < k < m, in 
Py = (hh, Ig,..., Im) is 21 + 1-bit stable. Consider P, 
as a dynamical system. Program ?, is structurally stable 
because whenever D(P1, P2) < | each instruction J; in 
P2 that corresponds to I; is resolved to the same opcode 
and same operand(s). Thus, the dynamical (computing) 
behavior of P} is the same as program P2. 


6.4. Hiding Operands and Opcodes in Noise 


In 6.2, we provided procedures 1, 2, and 3 for 
building opcodes stable to small changes. When 
these procedures are also applied to operands, the 
representation of the operands can become stable to 
small changes. In our model, Eve is a sentient adversary, 
so structural stability from classical mathematics alone 
does not provide enough mathematical firepower to 
build malware resistant computation. Hence, the 
purpose of design goal B is to build a representation of 
each instruction that is computationally intractable for 
Eve to understand its meaning. 

Procedure 4 builds a permutation based on [18, 19]. 
Procedure 4. 
Input: n 
set p(1):=1 
set k:=n 


while k>2 
{ 


Random Permutation p 


set p(2):=2 





set p(n) :=n 


use q to randomly choose positive 
integer r in the set {1,...,k} 


decrement k by 1 
} 


Output: Permutation p on {1,...,n} 


Procedure 5 uses procedure 4 to build a random 
substitution box. 


Procedure 5. Random Substitution Box a 


Input: 


call procedure 4 with input n= 2" to 
create random permutation a 


Output: Substitution Box ao 
o maps an 7-bit input to an n-bit output 


The rest of this subsection describes how to hide 
the meaning of the opcodes and operands from Eve. 
Procedures 4 and 5 have different purposes even though 
they both produce a random permutation. Procedure 5 
constructs a o that has size 2”. Typically, 7 = 8 because 
8 bits is a byte, and n = 16 is too large.’ If the operands 
in the base virtual machine have size equal to 64 bits 
before hiding in 64 bits of noise, then procedure 5 is 
called sixteen times to generate 0; 02 ... o1ig for the 
first operand. For the second operand, procedure 5 is 
called sixteen more times to generate 017 ... 032. In 
general, o; and o; are statistically independent when 
i # J, as result of using procedure 5, based on [19]. 

Procedure 4 builds p to locate the 64 bits of the 
signal b;bz ... bg4 inside the random noise. p lies in 
the symmetric group on {1,2,...,n}, and determines 
where each bit of the signal (i.e., opcode or operand) is 
located: the ith bit b; is stored at bit location p(i), where 
1 <i < 64. When there are 64 bits of signal from 
the operand or opcode and 64 bits of quantum random 
noise, then the size of p is 128, 1.e.,n = 128. 

Random noise is measured and _ stored in 
the remaining 64 bit locations. The result is 
128 bits of noise and signal, named s 1... Sys. 
Subsequently, the 16 randomly generated sboxes 
o; with 1 < a < 16 are applied to 5,52... 5108 


as follows: 01(8182835485868788), 02(S9... $16), 

016($121$122512381245125$12681275128), | Which 
is named cC1C9... Cy. Next, a distinct random 
permutation 7 is generated on {1,2,...,128}. 


T is applied to c,co...Ci2g, resulting in Cr(1) 

C7(2) +--+ Cr(12g). Then sixteen distinct sboxes ay 

Qig are randomly generated and applied to 

Cr(1)Cr(2) ++ - Cr (128) as follows: 11 (€r(1) Cr(2) sae Cr(g)) 
- 16 (C-(121) --- Cr(128) ), Tesulting in 01 .. . 0128. 

In subsection 7.2, a birthday paradox statistical 
test is described in order to address potential attacks 
that involve stable instructions of size 128 bits. The 
birthday attack test performs 2’ compilations of the 
same unmasked instruction. In 7.2, we also describe 
a Statistical test to address multiple transformations via 
procedure 6 of the same instruction at different locations 
in a single SVM compilation of the program. 

7If 7 = 16, then o has size 216 = 65536. If 7 = 16, then a is 


considerably more expensive than 7 = 8. Our goal is to store o in 
protected machine hardware (Figure 2) that is not accessible to Eve. 
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For each time the SVM compilation tool is executed, 
all p, o;, T, a; and randomized opcodes are statistically 
independent from each other and from all previous 
compilations. Also, within one SVM compilation, the 
random noise (n — k bits per opcode) generated for two 
identical opcodes at different locations in the program is 
statistically independent. 

From our prior description, procedure 6 formally 
specifies hiding a k-bit opcode (or operand) 6; ... by 
in n — k bits of random noise. p and 7 are distinct 
random permutations on {1,2,..., 7}. determines the 
bit locations of b; . . . bj hidden inside of noise. 01... Tp 
and a1 ...@, are random sboxes. 


Procedure 6. Hide in Noise 
Input: k,n and k-bit string bi bo... br 


call procedure 4 with input nto build 
random permutation p on {1,2,...,n} 


call procedure 1 with input n and store 
noise in every bit location lh lz... In 


set g:=l 


while j<k 
{ 


set bit location Ip(j) := b; 

increment 7 by 1 
} 
call procedure 5 p times on input 7 and 
generate substitution boxes 01...0p 


apply substitution boxes 01...d0p to input 
ly lg... In and compute ci C2... Cn 


call procedure 4 with input nto build 
random permutation 7 on {1,2,...,n} 


permute C1... Cn tO C,(1) --- Cr(n) 


call procedure 5 p times on input 7 and 
generate substitution boxes aj,...Qp 


apply a1...Q@p to input C7(1) --. Cr(n) 
Output: 01 02... On 


6.5. Hiding Instruction Order 


Procedure 7 hides the hidden stable instructions, 
constructed by procedure 6, inside a block of size b 
containing dummy instructions. 6 is the sum of the 
number of stable instructions and the number of dummy 
instructions in the block. m is the maximum number of 
stable instructions hidden. is a random permutation on 
{1,2,...,b}. $4, So, ..., Sm are a sequence of stable 
instructions that are part of the program. 


Hide Stable Instructions in Block 
and Sin 


Procedure 7. 
Input: b,m,y, and Si, S,... 


use q to randomly choose a positive 





integer c in the set el aracdilen| 
set 7:=1 set j:=1 set k:=1 
while i<b 


{ 


use q to randomly choose a positive 
integer r in the set {1,2,...,b} 

if ((r<c) and (j<m)) 

{ 


hide instruction S; at location y(t) 


increment 7 by l 


} 


else 


{ 


randomly build dummy instruction Dx 
hide instruction Dz at location 47(t) 


increment k by 1 


} 


increment 7 by 1 


Table 1 shows a representation of the stable 
hidden instructions permuted in the block with dummy 
instructions after procedure 7 is completed. 


Table 1. Hiding Instruction Order 








Block Instr. Instr. Test Gamma 
Index Name Type r<e Index 
1 Sy Valid True (j1) 
2 Dy, Dummy False y(r1) 
yd) S41 Valid True y(1) 
b Dy Dummy False 9(rR-1) 
In table 1, j; = y~1(i) and r; = y~1(i). 
Because c is randomly selected in {1,... ||}, and 


m is determined during compilation and m can be 
randomly selected for each block, Eve does not know 
how many valid instructions are in a block. Eve does 
not know the probability distribution of valid versus 
dummy instructions in a block; and Eve does not know 
the block size. Eve does not know y, and she does 
not know how to distinguish a dummy opcode from a 
valid opcode, since the dummy opcodes are also selected 
using procedure 1. 

In our cryptographic model, Alice’s Protected 
Machine Hardware (Figure 2) should execute the 
operations in procedures 6 and 7 because the sboxes 
01...0p and a, ...Q, and permutations p, T, y “act 
as Alice’s private keys.” 
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6.6. Executing Stable, Hidden Instructions 


After the inverse of procedure 7 is performed on 
a block of the program, executing a stable, hidden 
instruction consists of 3 steps. 


1. Unmask and find the nearest valid opcode. 
2. Extract the operands from the noise. 
3. Execute a valid instruction. 


In our cryptographic model, we assume there is 
at least one hardware implementation where all three 
steps are executed in Protected Machine Hardware (blue 
region in Figure 2). Our model assumes Eve does not 
have access to the internal physical operations in the 
blue region during the execution of these three steps. 

With our model assumption, we proceed to examine 
steps 1, 2, and 3 in more detail. We developed a software 
tool, called SVM, in ANSI C [14] that performs these 
3 steps. Our SVM tool uses the quantum random 
bit generator in [20]. In general, our SVM tool can 
execute any hidden program that operates according to 
the virtual register machine instructions, described in 
section 6.1. After a brief summary of steps 1, 2, and 3, 
we demonstrate an example of our SVM tool, building 
hidden, stable virtual register machine instructions. 

We assume that our cryptographically stable 
instructions are stored in Unprotected Memory (Figure 
2). After a block of hidden instructions are retrieved 
from Unprotected Memory, they are ordered, unmasked 
and executed in the Protected Machine Hardware. In 
step 1, the first argument of the instruction is a noisy 
opcode. Our SVM tool finds the nearest valid opcode to 
the noisy opcode, by computing the Hamming distance 
between the noisy opcode and valid opcodes. If the 
nearest opcode is a dummy opcode, the instruction is 
ignored; otherwise, in step 2, the operands are extracted 
from the noise by executing a procedure that performs 
the inverse of procedure 6. In step 3, a valid opcode 
executes with unmasked operands as input. 


Example 1. © Unmasked GCD Program 


Symbols, following a semicolon on the same line, are 
comments. 


SET A 6 ; Instruction 0 

SET B 10 ; Instruction 1 

IF A 0 ; 2. If (A == 0) execute instruction 3. 
JMP 12 ; 3. Branch to instruction 12. 

IF B 0 ; 4. If (B == 0) execute instruction 5. 
JMP 13 ; 5. Branch to instruction 13. 

IFGT A B ; 6. If (A > B) execute instruction 7. 
SUB A B j; 7. Store A-B in register A. 

IFGT B A ; 8. If (B > A) execute instruction 9. 
SUB B A ; 9. Store B-A in register B. 

IFN A B ; 10. If (A != B) execute instruction 11. 
JMP 2 ; 11. Branch to instruction 2. 

SET A B ; Instruction 12 

SET B A; Instruction 13 


GCD Instructions Executed: 


SET A 6 
SET B 10 
IF A 0 
IF B 0 
IFGT A B 
IFGT B A 
SUB BOA 
IFN A B 
JMP 2 

iF A 0 
IF B 0 
IFGT A B 
SUB A B 
IFGT B A 
SUB BA 
IFN A B 
SET A B 
SET BOA 


After the last instruction SET B A executes, both 
registers A and B are storing 2. Instruction numbers in 
an SVM program always start at 0, so JMP 2 causes 
the SVM to execute IF A 0. In the next section, we 
analyze what our stable instructions look like to Eve in 
Unprotected Memory after multiple SVM compilations. 





7. Complexity, Statistics, & Performance 


We estimate the complexity of our hiding procedure, 
and estimate memory use and computing time. 


7.1. Complexity Estimate 


We use the same parameter values as in 6.4. For 
larger registers, the complexity scales favorably because 
f(n) = n! grows much faster than e(n) = 2”. 


Calculating oe with sizes 128 and 256 bits: £ ee € 





[10!77, 10178] and ioe. € [104°°, 1048"). f(n) is 





compared to binary exponential growth e(n) because 
procedures 4, 5 and 6 use permutations; standard 
cryptographic methods rely on the P 4 N P assumption 
that complexity grows exponentially. In procedure 6, 
each 64-bit opcode (& = 64) is hidden in 64 bits of noise 
(n = 128). There are 128 « 127...66 * 65 > 10126 
locations for hiding a 64-bit operand in 64 bits of noise. 


7.2. Statistical Testing for Two Attacks 


The first test searches for a birthday paradox attack 
with distinct SVM compilations of a fixed 64-bit random 
opcode in the unmasked instruction SET A 6. 

We used n = 64 for procedure | to generate the 
random opcode for SET, and inputs 1 = 12, m = 12, 
and n = 64 for procedure 3. We used input n = 128 for 
procedure 4; and input 7 = 8 for procedure 5; and inputs 
ki = 64 and n = 128 for procedure 6. We searched 
for collisions, where 75% of the bits match: that is, 
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where the Hamming distance was greater than 96 for 
two opcode portions of the instruction SET A 6. 

The statistics for 44850 Birthday paradox collision 
search comparisons are shown below, where each tally 
is the hamming distance between two 128-bit hidden 
opcodes, generated from instruction SET A 6. Let h; 
be the number of pairs of distinct stable instructions 
whose 128 bits of opcode are a Hamming distance of 
i bits apart. Below is the data for a typical run with 300 
stable instructions generated from SET A 6: 











TOTAL number of h; computed = 44850. 
hao 4, har 1. haz 0. hag 2. haa A. has 6. hae 14. 




















haz 33. hag 64. hag 87. hso 150. Asi = 237. hse = 328. 
hs3 = 460. hsa = 667. hss = 902. hse = 1114. hs7z = 1451. 
hs5g = 1809. hs5g9 = 2142. hen = 2516. her = 2795. he2 = 2927. 
he3 = 3068. hea = 3157. hes = 3184. hee = 2929. hez7 = 2729. 
hes = 2492. heg = 2100. h7o = 1809. h71 = 1522. h72 = 1115. 
h73 = 929. hrs = 676. h75 = 480. h7g = 361. hrz = 219. 
hzg = 145. hz9 93. hso 57. hei 38. hge 18. hes 12. 
hga = 1. hgs = 6. Wheni > 85,h; = 0. 


Empirical mean = 64.02. js = 64. Expected standard deviation o = 5.66. 
30039 h, are within o of yw. Expected h; within o = 30615. 

42973 h, are within 20 of yw. Expected h; within 20 = 42805. 

44714 h, are within 30 of jw. Expected h; within 30 = 44733. 


No Hamming distances were close to 96 (75% of 128). 


In test 2, we searched for an attack by looking 
at multiple compilations of the same instruction at 
different locations in a single SVM compilation of the 
program. To simplify this search and make an attack 
easier to find, we built a program with 150 identical 
instructions: SET A 6. After this single compilation, 
we computed pairwise Hamming distances. Statistics 
for a typical run of test 2 are shown below: 





TOTAL number of h; computed = 11175. 


haz 4A. haa 2. has 3. hae 4. haz 7. hag 15. hag 30. 
hso 43. hs. 43. hso 75. hs3 D2. hsa = 167. hss = 237. 














hse = 309. hs7z = 389. hsg = 467. hs9 = 520. heo = 648. 
hei = 667. he2 = 701. hes = 753. hea = 867. hes = 782. 
hee = 697. hez = 670. heg = 655. heg = 535. h7g = 437. 
hz => 345. hz2 = 259. hz3 =. 223: hza = 168. h7s => 117. 
hz 82. h7zz 46. hzg 37. h7z9 23. hso 10 her T. 




















hgo 6. hg3 1. hga 1. Ags 1. When i > 85, hy = 0. 





Empirical mean = 63.90. js = 64. Expected standard deviation o = 5.66 
7495 h; are within o of js. Expected h; within o = 7628. 

10735 h, are within 20 of w. Expected h; within 20 = 10665. 

11139 h, are within 30 of jz. Expected h; within 30 = 11146. 

No Hamming distances were close to 96; the 
statistics follow a binomial distribution with p = 5. In 
general, we do not expect this attack to be effective for 
Eve because Alice should not voluntarily compile her 
plaintext code with static “keys” on plaintext code that 
repeats the same instruction multiple times on purpose. 
Furthermore, Eve’s potential collisions occur only on 
“keys” that Eve artificially constructs with the SVM 
tool. In a proper use setting, Alice uses a different 
set of “keys” and randomized opcodes on each separate 
compilation on a particular machine, and procedure 7 
further reduces the efficacy of this type of attack. 


7.3. Hardware Performance Estimates 


In section 6.4, 64-bit operands (or opcodes) are 
hidden in 64 bits of noise (k = 64, n = 128). If 
we assume that we are not utilizing 56 out of the 64 
bits that represent the opcode, then our memory use in 
unprotected memory increases linearly at most by 42. 

We use Shi and Lee [21] as a reference to estimate 
computing speeds of our bit permutations executed in 
Protected Machine Hardware (procedures 4 and 6). Shi 
and Lee rigorously analyze implementing arbitrary bit 
permutation operations in hardware. Their complexity 
estimates are expressed in terms of logical effort [22]. 
Logical effort can be used to estimate the number of 
stages required to implement the critical path of a given 
logic function with CMOS, and determine the maximum 
possible speed of the circuit. 

In [21], they found that the Butterfly network is the 
fastest architecture for implementing bit permutations. 
For a 6-stage Butterfly network they found a latency 
of 12.0 FO4 [23]. Microprocessors typically have a 
cycle of time of 20-30 FO4, so the Butterfly network 
should be able to complete all bit permutation operations 
in | or 2 instruction cycles. The generation of the 
quantum random bits can be performed offline to 
support procedures 1-7. (The inverses of procedures 6 
and 7 do not require a quantum random bit generator.) 


8. Related Work 


In [24], they present a general approach to 
addressing code-injection attacks in scripting and 
interpreted languages (e.g., web-based SQL injection), 
by randomizing the instructions. In [24], they do 
not address malware attacks at the machine instruction 
(physical hardware) level; there is no notion nor use of 
stability to build instruction opcodes and operands that 
are resistant to small changes. 

Fully homomorphic encryption (FHE) [25] is a 
clever method for protecting Alice’s computations on 
data in the cloud. However, FHE does not use stability, 
and does not protect the computer instructions that store 
the private FHE key. FHE defers the malware problem 
to the user’s local computer; FHE does not address 
how to hinder malware on the local computer. Some 
FHE keys are 1 Gigabyte and the plaintext-to-ciphertext 
expansion is 10,000 to 1 for just 100 bits of security [26, 
27]. FHE’s huge memory requirements are not currently 
economically feasible for protecting instructions in 
hardware. From section 7, we see that procedures 1-7 
surpass FHE by many orders of magnitude when one 
compares the amount of complexity obtained for a given 
amount of memory and computing speed. 
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Secure multi-party computation (MPC) [28, 29] 
enables a group to jointly perform a computation 
without disclosing any participant’s private inputs. MPC 
does not address when Alice does not trust her own 
machine, or the machine instructions being executed on 
her machine. With further research, it is conceivable that 
the stability and / or hiding methods described herein 
could be integrated into hardware with an augmentation 
of one or more of the MPC protocols. 

In [30], a parallel machine uses quantum 
randomness and_ self-modification to emulate the 
execution of a Universal Turing machine so that the 
firing patterns of the parallel machine’s active elements 
are random to an outside observer. A _ procedure, 
described in [30], requires a novel neuromorphic 
hardware architecture to effectively implement a 
quantum random blackbox. 


9. Summary 


Malware can subvert the purpose of a register 
machine program, by changing only one address in one 
instruction. We built an SVM software tool (coded in 
ANSI C) that implements a Turing complete, stable 
virtual machine. Our SVM tool hides the operands and 
opcodes in unprotected memory with a complexity that 
exceeds FHE, and the tool’s procedures are feasible to 
implement in current processors. A red team should 
test under what conditions our cryptographically stable 
virtual machine is resistant to sabotage. 
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